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Notes  for  Slide  1 


Summary 

This  presentation  provides  an  overview  of  computer  generated  forces 
simulations.  Computer  generated  forces  have  applicability  to  all 
aspects  of  defense  analyses,  including  training,  mission  rehearsal, 
force  structure  assessments,  and  system  acquisition.  The  basic 
simulation  architecture  is  presented  along  with  discussion  of  the  key 
technical  areas.  Issues  bearing  on  future  development  of  computer 
generated  forces  are  also  presented. 
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Topics 


•  Definition  of  Computer  Generated  Forces 

•  Simulation  System  Architecture 

•  Broad  Range  of  Applications 

•  5  Technical  Areas 

•  Issues 
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The  purpose  of  this  presentation  is  to  give  a  basic  understanding  to 
how  CGFs  are  constructed.  It  discusses  the  main  elements  of  the 
overall  architecture  of  a  simulation  system,  giving  a  context  for  the  CGF 
part  of  the  system. 

Five  basic  technology  areas  are  reviewed:  Synthetic  Environment, 
Simulation  Systems  Architecture,  Modeling  of  CGF,  Human  behavior 
Representation,  and  Human-System  Interactions. 

CGFs  will  be  under  active  development  for  the  foreseeable  future.  The 
key  issues  guiding  this  development  are  discussed. 
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Simulation  System  Architecture 
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A  simulation  system  will  have  many  different  kinds  of  components:  CGFs, 
Synthetic  Environments,  Models  of  domain  entities,  forces,  tasks,  Analysis 
Tools,  Scenario  Generation  Tools,  Visualisation  Tools,  Mobile  Devices, 
Multimodal  Human-Machine  Interfaces,  C4I  systems,  Embedded  evaluation 
and  monitoring  agents,  algorithms  for  continuous,  discrete  event  and  Monte 
Carlo  simulations,  embedded  tutor  components,  tools  for  after  action  review, 
and  many  other  kinds  of  automated  assistance.  In  addition  to  these  resources 
that  have  immediate  utility  to  the  user,  there  are  a  number  of  resources  that  are 
necessary  components  to  managing  these  resources  in  a  flexible  way;  they  are 
indirectly  seen  by  users  in  the  ease  with  which  the  system  can  be  tailored 
because  of  the  needs  of  different  users,  new  field  requirements  or  new  parts  of 
the  system.  Among  these  types  of  components  are  domain-specific  models 
that  define  the  configuration  for  a  subset  of  components,  with  the  detailed 
specializations  that  will  allow  them  to  be  tailored  for  a  given  application. 
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Notes  for  Slide  3  (Continued) 


We  need  flexibility  in  the  architecture,  because  components  and  even 
architectures  change  with  technology.  That  is,  the  variety  of  components,  the 
different  kinds  of  uses  of  components,  and  the  dynamic  nature  of  technology, 
together  require  a  flexible  interconnection  architecture.  It  is  therefore  necessary 
to  define  the  semantics  of  the  shareable  data,  that  is,  the  meanings  that  the 
users  of  that  data  are  expected  to  attach  to  it,  rather  than  fixing  the  structure  if 
the  systems  that  will  use  the  data.  It  is  convenient  to  define  the  syntax  of  the 
data  (data  formats  and  structures),  but  not  nearly  as  important  as  defining  the 
semantics.  If  the  data  syntax  is  explicit  for  each  data  item,  then  it  can  be 
translated  or  converted  appropriately  as  needed. 
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Technologies 


Synthetic  Environment 
Simulation  Systems  Architecture 
Modeling  of  CGF 
Human  behavior  Representation 
Human-System  Interactions 
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Synthetic  environments  are  the  computerized  representations  of  the 
natural  and  man-made  environment. 

Simulation  system  architecture  deals  with  how  to  construct  and 
organize  CGFs  so  that  they  communicate  well  between  them  and  their 
environment. 

The  next  two  topics  deal  with  the  modeling  of  CGFs  in  general,  i.e.  the 
interaction  between  the  virtual  human  and  virtual  physical  entities,  and 
the  methods  for  representing  and  modeling  the  outcomes  of  what  in  the 
real  world  are  human  behaviors  and  related  decision  processes. 

Human-system  interactions  encompasses  technologies  for  interfacing 
the  CGF  with  a  human  decision  maker  or  other  operator. 
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Synthetic  Environments 


A  definition: 

Synthetic  Environments  (SE)  are  computerized 
representations  of  the  natural  and  man-made  environment 
that  are  amenable  to  simulations  of  man-made  or  naturally 
occurring  processes. 

Typically,  SEs  comprise  representations  of  land,  sea,  air, 
space,  and  man-made  features  and  structures. 
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Synthetic  environments  form  the  basis  of  all  combat  simulation,  and 
other  simulations  such  as  those  for  factory  production,  urban  traffic, 
weather,  and  the  like. 

The  main  research  in  SEs  deals  with  the  creation  of  more  detailed 
synthetic  environments  and  the  creation  of  validated,  sharable  (by  a 
variety  of  simulation  systems)  synthetic  environments. 

Synthetic  Environment  are  represented  to  an  appropriate  level  of  detail 
required  for  the  particular  application  domain.  Synthetic  Environment 
allows  the  realistic  interaction  of  CGF  components  rather  than  just  their 
visualisation. 
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Key  Research  Areas  of  Synthetic 
Environments  (continued) 

•  Content 
-Composition 
-Correlation 


8-13 


Notes  for  Slide  6 


Content  relates  to  the  elements  that  should  be  included  within  the 
Synthetic  Environment  at  an  appropriate  level  of  representation,  and 
ensuring  correlation  between  the  applications.  Two  specific  research 
areas  were  identified  under  content. 

Composition.  Specifically  what  components  of  the  physical  environment 
should  be  included  and  defining  the  level  of  detail  required,  examples 
include:  micro  terrain,  weather  effects,  illumination  sources,  air  and  sea 
state,  objects  (buildings,  vehicles,  etc)  and  their  associated  properties. 
These  models  must  also  include  a  description  of  their  properties  to 
allow  proper  interaction,  and  also  to  ensure  consistency  between  the 
different  applications. 
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Correlation.  This  is  somewhat  related  to  representation,  but 
concentrates  on  the  mechanisms  which  could  be  used  to  ensure  there 
is  correlation  of  the  data  at  different  levels  of  representation  (e.g. 
aggregated  versus  dis-aggregated),  and  between  different  simulation 
applications,  especially  when  data  is  derived  from  different  sources. 
Correlation  must  also  be  maintained  in  the  temporal  domain  in  addition 
to  the  static  case,  e.g.,  during  a  CGF  simulation  the  environment  may 
change  (due  to  weather,  dynamic  effects,  etc.) 
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Key  Research  Areas  of  Synthetic 
Environments  (continued) 


•  Production 

-Automatic  data  collection  and 
processing 

-Definition  of  requirements 
-Verification  and  validation 
-Representation 
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Production  relates  to  the  initial  definition  and  creation  of  the  synthetic  environment 
representation.  Four  research  areas  were  identified  in  this  categorisation. 

Automatic  data  collection  and  processing.  The  process  of  collecting  data  and  processing 
has  been  traditionally  manpower  intensive.  Thus  there  is  a  requirement  to  automate  this 
process  in  an  error  free  manner  and  including  the  only  appropriate  information.  Also, 
typically  many  systems  require  different  formats  of  the  data  in  order  to  operate  efficiently, 
thus  a  generic  interchange  mechanism  is  required  to  allow  accurate  translation  of  the 
data  to  different  formats.  There  are  a  number  of  facets  to  Data  Collection;  firstly,  due  to 
the  complexity  of  collecting  the  data  from  sources  (e.g.  satellite  images),  and  correlating 
data  from  different  sources  progress  in  this  area  is  seen  as  longer  term.  Secondly,  the 
process  of  data  collection  must  be  seen  as  a  continuous  process  reflecting  that  the 
environment  and  simulation  models  are  continuously  changing.  Currently,  there  are 
programmes  examining  the  process  of  data  interchange  (e.g.  SEDRIS).  Although  there 
are  a  number  of  research  programmes,  (e.g.  using  Global  Co-ordinates),  it  is  viewed  that 
basic  research  is  still  required  (e.g.  to  process  the  basic  images  to  extract  terrain 
features). 
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Defining  Requirement.  When  SE’s  are  used  it  is  important  to  define  the  requirement 
which  that  Synthetic  Environment  should  fulfil  in  order  that  the  needed  components  can 
be  included  at  an  appropriate  level  of  detail. 

Verification  and  Validation.  This  area  encompasses  the  problems  of  ensuring  the  data 
are  correct,  consistent  when  merging  different  sources,  the  problem  of  co-ordinates  on 
very  large  databases  (curved  earth),  and  integrity  (i.e.  ensuring  consistency  between 
simulation  sites,  and  that  the  data  has  not  been  changed  by  an  unauthorised  party). 

Representation.  This  area  extends  to  include  representation  at  multiple  levels  of 
simulation  and  between  different  applications.  Taking  the  first  point,  CGFs  increasingly 
include  a  number  of  command  levels,  each  of  which  places  different  demands  on  the 
Synthetic  Environments  representation  (i.e.  the  level  of  detail).  Similarly,  different 
applications  will  require  different  emphasis  on  the  data,  for  example  comparing  a  CGF  to 
a  visualisation  system. 
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Key  Research  Areas  of  Synthetic 
Environments  (concluded) 

•  Use 

-Environmental 

reasoning 

-Dynamic  terrain 

-Data  distribution 
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Use  relates  to  the  actual  use  of  Synthetic  Environments  during  simulations.  Research 
areas  include  the  following: 

Environmental  Reasoning.  This  is  not  how  to  perform  reasoning  but  the  required 
representation  within  Synthetic  Environments  in  order  to  successfully  support  the 
reasoning.  Specific  problems  identified  include:  identification  of  significant  features  during 
the  course  of  an  operation,  intelligence  preparation  of  the  battlefield,  inclusion  of  land, 
sea  and  air  state,  and  environmental  effects.  All  these  effects  are  computationally 
expensive  especially  compared  to  the  bandwidth  required  to  transmit  the  information. 
Thus  it  is  undesirable  to  duplicate  this  processing  on  each  application  but  instead  use  a 
central  server(s)  and  transmit  the  required  information  over  the  network. 
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Dynamic  Terrain.  During  the  course  of  a  simulation  it  is  likely  that  the  state  of  the  terrain 
changes  due  to  various  effects.  This  includes  the  environment  itself  by  for  example 
weather  effects,  cratering,  and  objects  such  as  buildings,  bridges  (which  are  tactically 
very  significant).  Each  of  these  effects  need  to  be  generated,  updated  in  all  participating 
simulations  in  a  timely  manner  (i.e.  maintaining  time  correctness).  The  generation  of  such 
effects  should  be  “transparent"  to  the  environmental  reasoning,  i.e.  any  system  reasoning 
about  the  environment  should  not  be  aware  of  any  “special"  processes  or  objects.  Unlike 
environmental  effects,  the  processing  of  changes  to  the  environment  are  not  generally  as 
computationally  expensive,  and  because  of  the  rapid  data  access  required  by  CGFs  the 
processing  should  be  done  locally. 

Data  Distribution.  This  area  address  the  problem  of  distributing  databases  between  sites, 
the  availability  of  the  data,  and  selecting  appropriate  components.  One  of  the  main 
problems  is  that  although  there  are  a  large  number  of  databases  available,  more 
common  than  not  is  the  difficulty  of  access  to  the  data.  In  order  to  prevent  duplication  and 
facilitate  easy  common  access  to  data  (which  can  then  be  centrally  configuration 
managed)  a  central  repository  with  easy  access  is  required.  Accessing  the  data  can  be 
either  on-line  (i.e.  internet)  or  off-line  (i.e.  tape  distribution).  The  former  poses  more 
technically  challenging  because  of  the  need  to  maintain  security  and  integrity  of  the  data. 
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Simulation  System  Architecture 
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Simulation  Architectures 


•  Emerging  Architectural  Concepts 

-  CGFs  are  meaningful  only  within  a  context  that  includes  an  entire 
simulation  (or  operational)  SYSTEM:  the  CGFs,  the  MMIs,  the 
Synthetic  Environment,  the  human  behavioral  models  (HBMs)  and 
other  components 

-  Future  uses  of  CGFs  will  involve  applications  requiring  the  integration 
with  live  systems  (e.g.,  C4I),  the  incorporation  of  multi-modal  man- 
machine  interface  devices,  the  flexible  combination  of  different  CGFs, 
and  the  embedding  of  the  CGFs  into  very  different  types  of  synthetic 
environments 

-  Architectural  frameworks  must  enable  flexible  and  open  architecture 
for  the  future  applications  of  CGFs. 

-  Flexible  architectures  allow  leveraging  commercial  partners;  they  can 
participate  to  different  degrees. 
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There  is  more  to  military  simulation  systems  than  the  important  content  of  the 
CGFs  themselves. 

CGFs  are  only  meaningful  within  a  context  that  includes  an  entire  simulation  (or 
operational)  SYSTEM:  the  CGFs,  the  MMIs,  the  Synthetic  Environment,  the 
human  behavioral  models  (HBMs)  and  other  component. 

Although  CGFs  may  indeed  be  useful  in  a  number  of  applications  not  requiring 
all  of  the  above  components,  many  of  the  future  uses  of  CGFs  will  involve 
applications  requiring  the  integration  with  live  systems  (e.g.,  C4I),  the 
incorporation  of  multi-modal  man-machine  interface  devices,  the  flexible 
combination  of  different  CGFs,  and  the  embedding  of  the  CGFs  into  very 
different  types  of  synthetic  environments.  The  issue  here  is  to  not  just  develop 
an  architecture  that  can  allow  reasonable  interoperability  of  today’s  CGF 
components  and  capabilities,  but  rather  to  set  down  the  framework  and  issues 
in  order  to  create  an  appropriately  flexible  and  open  architecture  for  the  future 
wide-ranging  applications  of  CGFs. 
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The  required  flexibility  and  openness  is  not  only  for  the  economic  and  scientific 
benefits  of  quickly  building  CGF  applications  out  of  existing,  diverse 
components,  but  also  to  give  different  organizations  the  flexibility  to  participate 
to  the  extent  that  they  want  to  in  different  applications,  while  still  retaining  the 
advantages  of  leveraging  other’s  investments  and  developments  in  this  area. 
This  is  an  important  part  of  the  strategy  for  leveraging  off  the  commercial 
marketplace  while  retaining  the  requirements  for  specialised  military  systems; 
flexible  architectures  allow  commercial  partners  to  participate  to  different 
degrees. 
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Desirable  Attributes  of  Simulation  Architecture 


•  Customer  pull  as  a  well  policy  push 

•  Sharable,  reusable  architectures,  components,  and 
infrastructures 

•  Increased  object  reuse;  decrease  system  risk,  time  to 
insert  the  technology,  and  model  development, 
maintenance  costs 

•  Interoperability  is  a  matter  of  degree 

•  A  simulation  object  repository 

•  Common  transport  layers,  common  messaging  systems, 
and  neutral  data  formats 

•  Semantic  integration  via  common  ontologies  is  the 
critical  challenge. 

•  Open  architecture  and  protocols  track  trends  and 
standards  in  the  commercial  world 
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Successful  architectures  have  to  be  driven  by  customer  pull  as  a  well  a  policy 
push  otherwise  they  will  become  obsolete  due  to  economic  forces. 

Heterogeneous  communities  may  require  different  architectural  services  with 
different  constraints  at  each  layer.  Appropriate  incentives  can  help  individual 
and  groups  to  see  co-operating  in  shareable  architectures  as  an  advantage;  the 
shared  infrastructure  and  reusable  components  must  be  harvested,  and  made 
easy  to  use  and  accessible  globally. 

A  good  simulation  architecture  should  increase  object  reuse,  decrease  system 
risk,  time  to  insert  the  technology,  and  eventually  model  development  and 
maintenance  costs. 

Interoperability  is  matter  of  degree,  depending  upon  the  needs  of  the 
simulation,  training,  and  C4I  communities. 
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A  simulation  object  repository  provides  information  on  objects,  their  public 
attributes,  associations,  interactions,  level  of  resolution,  and  key  models  and 
algorithms  used  to  represent  entities  in  the  simulation. 

Simulation  architecture  needs  common  transport  layers,  common  messaging 
systems,  and  neutral  data  formats  to  provide  limited  interoperability  and 
maximum  flexibility.  This  will  allow  commercial  companies  and  developers  to 
gradually  “buy-in”  to  joint  applications. 

Systems  integration  at  the  communication  level  is  a  necessary  but  insufficient 
goal.  Semantic  integration  via  common  ontologies  is  the  critical  challenge. 

Selection  of  open  architecture  and  protocols  needs  to  track  trends  and 
standards  in  the  commercial  world  in  order  to  leverage  off  commercial 
investments  for  specific  military  uses. 
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Interactions  of  Simulation  Architecture  with  Other 

Technology  Needs 


•  Automatic  configuration  and  inclusion  of  simulation 
objects  (including  models)  from  repositories 

•  Decision  processes  connected  to  simulation  elements 

•  Human  controlled  allocation  of  decision-making  by  CGFs 

•  Support  for  different  sources  of  information  input  and 
output 
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These  is  a  need  for  flexibility  in  the  architecture,  to  allow  different  approaches  to  hard 
problems  to  be  considered,  and  to  allow  rapid  construction  and  modification  of  problem- 
specific  simulations. 

The  automatic  configuration  and  inclusion  of  simulation  objects  (including  models)  from 
repositories,  the  availability  of  models  at  multiple  resolutions,  and  tools  for  construction 
and  composition  of  objects.  To  configure  an  object  automatically  requires  the  composition 
tool  to  have  the  right  kind  of  information  about  what  that  object  is,  what  it  does,  in  what 
context  it  is  appropriate  to  use  it,  and  what  assumptions  or  limitations  are  built  into  it.  The 
architecture  should  support  the  use  of  explicit  selection  information  and  both  automatic 
and  semi-automatic  methods  of  using  that  information  to  configure  a  simulation. 

Decision  processes  connected  to  simulation  elements,  so  that  it  is  possible  to  include  a 
man-in-the-loop  in  the  simulation  support  side,  not  only  in  the  simulation  application 
subject  problem  area,  and  that  models  include  multiple  levels  of  command.  The 
architecture  should  support  explicit  interfaces  between  the  decision  processes  and  the 
simulation  components  requiring  decisions,  including  what  kinds  of  information  are  to  be 
made  available  to  the  CGF  by  the  simulation  and  what  kinds  of  decisions  it  can  make. 
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Models  have  multiple  levels  of  command,  and  the  architecture  should  allow  for  humans 
to  determine  what  decisions  are  made  by  CGFs  and  what  decisions  are  made  by 
humans. 

Realistic  voice  synthesis  (and  possibly  transport,  which  places  some  stringent 
constraints  on  the  acceptable  variability  of  information  delivery  times),  instrumentation  of 
mobile  entities  (e.g.,  users),  direct  manipulation  of  simulation  time  (i.e.,  compression  or 
expansion),  multiple  senses  (e.g.,  haptic,  tactile,  pressure,  smell,  taste),  and  the  use  of 
sound  for  location  (360  degrees,  up  and  down,  foreground  and  background).  The 
architecture  should  support  the  use  of  different  kinds  of  information  sources,  since  the 
architecture  should  not  depend  on  the  choice  of  which  models  to  use  in  a  particular 
simulation  run,  but  rather  the  architecture  should  help  make  it  easy  to  use  different 
collections  of  models  for  different  runs. 
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CGF  Architecture 
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The  role  of  each  of  the  modules  can  be  described  as  follows: 

The  data  collection  module  is  responsible  for  gathering  the  detailed 
data  elements  as  instructed  by  the  situation  assessment  module; 

The  situation  assessment  module  defines  the  detailed  data 
requirements  that  need  to  be  collected,  interprets  the  mission  received 
by  the  CGF,  updates  the  current  assessment  of  the  situation  and 
defines  and  monitors  critical  and  meaningful  events; 

The  option  generation  module  develops  courses  of  action  based  on  the 
triggering  event,  mission  statement  and  current  situation  assessment; 
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The  decision  making  module  evaluates  the  various  courses  of  action 
and  ranks  them  according  to  a  set  of  pre-determined  and  derived 
criteria.  It  will  also  support  the  negotiation  process  between  CGFs  or 
human  decision  makers  that  may  be  required  to  develop  a  solution  for 
the  larger  context  in  which  the  CGFs  decision  is  included; 

The  communication  module  supports  the  exchange  of  data  between 
the  CGF  and  all  other  elements  of  the  simulation  system.  It  transforms 
data  into  the  appropriate  format  for  local  and  external  interpretation. 
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Technologies  for  Modeling  CGFs 


Module 

Technology 

Data  Collection 

Current  database  and  browsing  technologies 

Data  mining  (e.g.  Selection  and  discrimination  techniques) 

Knowledge  discovery 

Pattern  recognition 

Knowledge  based  systems 

Current  database  and  browsing  technologies 

Situation  Assessment 

Knowledge  discovery 

Translation  techniques 

Rule -based  systems 

Task  and  domain  specific  data  fusion  algorithms 

Pattern  recognition 

Neural  networks 

Image  recognition 

Natural  language  processing 

Flexible  object  schema  for  situation  description 

Blackboards  for  consistency  maintenance 

Knowledge  based  systems 

Option  Generation 

Search  algorithms 

Simulation 

Knowledge  based  systems 

Operations  Research 

Fuzzy  logic 

Decision  Making 

Simulation 

Operations  Research 

Fuzzy  Logic 

Planning  techniques 

Search  techniques 

Cooperative  planning 

Communication 

Speech  recognition 

Gesture  recognition 

Image  generation 
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This  chart  shows  the  various  technologies  that  support  the  CGF 
functional  components. 

Continued  advances  are  needed  in  many  areas  to  enable  more 
sophisticated  CGF  behaviors.  For  example,  in  the  area  of  situation 
assessment,  the  CGFs  need  to  automatically  process  information  about 
their  environment  and  respond  appropriately.  This  information  can 
come  from  simulated  sensors  or  from  human  players  in  a  simulation 
exercise. 

A  second  key  area  is  option  generation.  To  be  able  to  demonstrate 
realistic  behaviors,  the  CGFs  must  be  able  to  examine  a  similar  range 
of  options  as  would  a  human  for  any  given  situation. 
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Human  Behavior  Representation 


•  HBR 

-  The  “thinking”  part  of  CGF 

•  Approaches 

-  Model  thinking  process 

-  Model  output  of  process 

-  Examples:  SOAR,  ModSAF 

•  Important  when 

-  Humans  affect  use  of  a  system 

-  Individual  differences  are  key 

-  Cannot  afford  to  use  real  people 


8-43 


Notes  for  Slide  15 


Human  behavior  Representation  (HBR)  is  the  most  difficult  issue  in  devising  successful  future 
CGFs  with  high  quality.  Technically,  one  can  think  of  a  HBR  as  a  software  module  that 
"interacts"  with  the  rest  of  a  CGF  and/or  with  the  real  world  -  depending  on  the  application. 
This  interaction  must  be  controlled  through  the  simulation  architecture,  via  HBR  objects  that 
access  information  from  real  or  simulated  sensors  through  real  or  simulated  C4I  systems. 

There  are  two  main  approaches  to  HBR.  One  is  mainly  concerned  with  mimicking  human 
thought  processes  and  is  hence  here  called  HBP  (Human  behavior  Process).  The  other  is 
more  concerned  with  a  correct  representation  of  the  output  of  a  thought  process,  and  is  here 
termed  HBO  (Human  behavior  Output).  The  implementation  of  HBR  in  software  is  referred  to 
as  HBM  (Human  behavior  Model). 
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HBR  emulates  human  behavior;  either  decision  processes  or  the  result  of  these.  Hence,  HBR 
should  be  used  whenever  the  outcomes  of  a  process  with  a  human  behavioral  element  is 
critical  to  the  overall  outcome  of  a  CGF.  The  prime  goals  of  a  behavioral  representation  in  a 
computing  process  are  to  enhance  the  quality  and  intelligence  of  the  CGF.  A  secondary 
consideration  is  to  make  applications  less  resource  intensive.  The  taxonomy  of  when  to 
include  an  explicit  focus  on  HBR  in  a  CGF  consists  of,  but  is  not  limited  to: 

When  the  human  significantly  determines  the  outcome  of  the  real  system  or  CGF. 

When  individual  differences  are  assumed  important,  and  sensitivity  analysis  of 
technical  parameters  are  not  sufficient  to  highlight  these  differences. 

Experimentation  requiring  faster  than  real  time  execution  (e.g.  the  real  human 
is  too  slow,  such  as  in  Monte  Carlo  simulation  used  for  analysis  -  or  the  time 
compression  needed  when  training  higher  level  commanders  in  operational  art). 

Cost  or  resource  savings  by  not  using  real  commanders  or  other  humans  are 
substantial. 

When  HBR  is  considered  in  a  CGF,  a  detailed  task  analysis  should  be  applied 
to  the  problem.  This  will  help  determine  which  HBR  issues  to  be  included  in  the  CGF. 
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Human-System  Interactions 


Natural  interface 


Time  compression 
Multi-modal 


Abstract  concepts 
Drill  down 

Agents 


Speech  recognition 

Video  conferencing 

Realistic  graphics 

Gestures  for  gross  manipulation 

Expansion  to  allow  students  to  catch  up 

Compression  to  save  time  or  to  create  stress 

Output:  audio,  still  &  motion  video,  graphics 

Input:  keyboard,  mouse/  trackball,  touch  panels, 
single  utterance  speech 

Video  conferencing 

Text,  maps,  flags,  simple  icons 

Lot  of  data  [problem  is  converting  to  information; 
primarily  self  selection] 

Organizers 
Push  technology 

Intelligent  agents  8-41 
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This  chart  lists  a  variety  of  modes  for  human-system  interactions. 

In  the  area  of  natural  interfaces,  multi-modal,  and  drill  down, 
commercial  research  and  development  will  address  most  defense 
needs. 

Defense  applications  particularly  benefit  from  advances  in  the  other 
areas.  For  example,  the  use  of  intelligent  agents  enables  a 
commander’s  staff  member  or  a  CGF  operator  to  more  effectively  work 
with  his  information  environment. 
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Key  Problems  for  Human-Systems  Interactions 


•  The  effects  of  time  compression  and  expansion  on 
learning  and  performance 

•  The  development  of  intelligent  agents  which  can  be 
subjected  to  verification. 

•  How  to  represent  abstract  concepts  in  operationally 
meaningful  terms 

•  The  effect  of  cultural  differences  on  interface  design  and 
effectiveness. 

•  Theory  of,  and  automated  means  for,  display  of  complex 
information 
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Some  of  the  human-system  interface  long-term  research  areas  for 
defense  applications  are  listed  here. 

These  problems  apply  to  both  CGFs  and  to  real  systems.  As 
information  technologies  make  it  possible  for  each  soldier  to  access,  or 
be  presented  with,  unlimited  amounts  of  data,  new  approaches  are 
needed  to  allow  the  user  to  effectively  obtain  just  what  he  needs,  at  just 
the  time  it  is  needed. 
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Issues 


Lack  of  appropriate  representation  of  group  and 
individual  behaviors 

Data  non-existent  or  difficult  to  collect 

Disconnected  tools,  little  common  use 

Little  validation  or  assessment  of  CGFs 


Expensive  to  use 
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A  more  common  data,  process,  and  software  basis  will  be  critical  for 
investigations  in  the  future.  To  effect  this,  the  following  areas  and 
characteristics  of  CGFs  need  improvement: 

Lack  of  appropriate  representation  of  group  and  individual  behaviors: 
In  current  applications,  the  representation  of  human  decision  making  is 
generally  restricted  to  the  lower  echelons.  At  higher  echelons,  greater 
flexibility  is  needed. 

Data  non-existent  or  difficult  to  collect:  CGF  decision  making 
capabilities  need  a  better  empirical  basis.  Little  data  has  been 
gathered  on  higher  echelon  behaviors  in  operational  environments. 
When  considering  future  concepts,  new  methods  are  needed  to  elicit 
such  data  and  make  them  computable  in  decision  making  terms. 
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Disconnected  tools,  little  common  use:  Most  CGF  systems  are  used 
independently  and  are  developed  without  the  benefit  of  common 
repositories  of  force  data,  descriptions  of  tactical  and  other  behaviors, 
or  the  ability  to  share  other  components  of  the  system,  e.g.,  the 
synthetic  environment. 

Little  validation  or  assessment  of  CGFs:  As  the  common  use  becomes 
more  widespread,  there  is  a  need  to  assess  CGF  performance,  both  to 
ensure  valid  multinational  representations,  and  to  provide  guidance  for 
what  must  be  improved  upon. 

Expensive  to  use:  CGF  systems  often  require  significant  amounts  of 
human  effort  in  the  set-up,  execution,  and  post-execution  analysis 
phases.  The  time  involved  and  the  systems’  inherent  flexibility  add  to 
the  overall  costs  of  use. 
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